Method and apparatus for personalizing secure elements in mobile devices

ABSTRACT

Techniques for personalizing secure elements in mobile devices to enable various secure transactions over a network (wired and/or wireless network) are disclosed. With a personalized secure element (hence secured element) in place, techniques for provisioning various applications or services are also provided. Interactions among different parties are managed to effectuate a personalization or provisioning process flawlessly to enable a mobile device for a user thereof to start enjoying the convenience of commerce over a data network with minimum effort.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application is a continuation of co-pending U.S. patent applicationSer. No. 15/000,041 filed on Jan. 9, 2016, now U.S. Pat. No. ______,which is a continuation of U.S. patent application Ser. No. 13/350,835filed on Jan. 16, 2012, now U.S. Pat. No. 9,240,009, which is acontinuation-in-part of co-pending U.S. patent application Ser. No.11/534,653 filed on Sep. 24, 2006, now U.S. Pat. No. 8,118,218, and alsoa continuation-in-part of U.S. patent application Ser. No. 11/739,044filed on Apr. 23, 2007, which is a continuation-in-part of co-pendingU.S. patent application Ser. No. 11/534,653 filed on Sep. 24, 2006, nowU.S. Pat. No. 8,118,218.

BACKGROUND Technical Field

The present invention is generally related to commerce over networks.Particularly, the present invention is related to techniques forpersonalizing a secure element and provisioning an application such asan electronic purse that can be advantageously used in portable devicesconfigured for both electronic commerce (a.k.a., e-commerce) and mobilecommerce (a.k.a., m-commerce).

Description of the Related Art

Single functional cards have been successfully used in enclosedenvironments such as transportation systems. One example of such singlefunctional cards is MIFARE that has been selected as the most successfulcontactless smart card technology. MIFARE is the perfect solution forapplications like loyalty and vending cards, road tolling, city cards,access control and gaming.

However, single functional card applications are deployed in enclosedsystems, which are difficult to be expanded into other areas such ase-commerce and m-commerce because stored values and transactioninformation are stored in data storage of each tag that is protected bya set of keys. The nature of the tag is that the keys need to bedelivered to the card for authentication before any data can be accessedduring a transaction. This constraint makes systems using suchtechnology difficult to be expanded to an open environment such as theInternet for e-commerce and/or wireless networks for m-commerce as thedelivery of keys over a public domain network causes security concerns.

In general, a smart card, chip card, or integrated circuit card (ICC),is any pocket-sized card with embedded integrated circuits. A smart cardor microprocessor cards contain volatile memory and microprocessorcomponents. Smart cards may also provide strong security authenticationfor single sign-on (SSO) within large organizations. The benefits ofsmart cards are directly related to the volume of information andapplications that are programmed for use on a card. A singlecontact/contactless smart card can be programmed with multiple bankingcredentials, medical entitlement, driver's license/public transportentitlement, loyalty programs and club memberships to name just a few.Multi-factor and proximity authentication can and has been embedded intosmart cards to increase the security of all services on the card.

Contactless smart cards that do not require physical contact betweencard and reader are becoming increasingly popular for payment andticketing applications such as mass transit and highway tolls. Such NearField Communication (NFC) between a contactless smart card and a readerpresents significant business opportunities when used in NFC-enabledmobile phones for applications such as payment, transport ticketing,loyalty, physical access control, and other exciting new services.

To support this fast evolving business environment, several entitiesincluding financial institutions, manufactures of various NFC-enabledmobile phones and software developers, in addition to mobile networkoperators (MNO), become involved in the NFC mobile ecosystem. By natureof their individual roles, these players need to communicate with eachother and exchange messages in a reliable and interoperable way.

One of the concerns in the NFC mobile ecosystem is its security in anopen network. Thus there is a need to provide techniques to personalizea secure element in a contactless smart card or an NFC-enabled mobiledevice so that such a device is so secured and personalized when itcomes to financial applications or secure transactions. With apersonalized secure element in an NFC-enabled mobile device, variousapplications or services, such as electronic purse or payments, can berealized. Accordingly, there is another need for techniques to provisionor manage an application or service in connection with a personalizedsecure element.

SUMMARY

This section is for the purpose of summarizing some aspects ofembodiments of the present invention and to briefly introduce somepreferred embodiments. Simplifications or omissions in this section aswell as the title and the abstract of this disclosure may be made toavoid obscuring the purpose of the section, the title and the abstract.Such simplifications or omissions are not intended to limit the scope ofthe present invention.

Broadly speaking, the invention is related to techniques forpersonalizing secure elements in NFC devices to enable various securetransactions over a network (wired and/or wireless network). With apersonalized secure element (hence secured element), techniques forprovisioning various applications or services are also provided.Interactions among different parties are managed to effectuate apersonalization or provisioning process flawlessly to enable an NFCdevice for a user thereof to start enjoying the convenience of commerceover a data network with minimum effort.

As an example of application to be provided over a secured element, amechanism is provided to enable devices, especially portable devices, tofunction as an electronic purse (e-purse) to conduct transactions overan open network with a payment server without compromising security.According to one embodiment, a device is installed with an e-pursemanager (i.e., an application). The e-purse manager is configured tomanage various transactions and functions as a mechanism to access anemulator therein. Secured financial transactions can then be conductedover a wired network, a wireless network or a combination of both wiredand wireless network.

According to another aspect of the present invention, security keys(either symmetric or asymmetric) are personalized so as to personalizean e-purse and perform a secured transaction with a payment server. Inone embodiment, the essential data to be personalized into an e-purseinclude one or more operation keys (e.g., a load key and a purchasekey), default PINs, administration keys (e.g., an unblock PIN key and areload PIN key), and passwords (e.g., from Mifare). During atransaction, the security keys are used to establish a secured channelbetween an embedded e-purse and an SAM (Security Authentication Module)or a backend server.

The present invention may be implemented in various forms including amethod, a system, an apparatus, a part of a system or a computerreadable medium. According to one embodiment, the present invention is amethod for personalizing a secure element associated with a computingdevice. The method comprises initiating data communication with aserver, sending device information of the secure element in respondingto a request from the server after the server determines that the secureelement is registered therewith, wherein the device information is asequence of characters uniquely identifying the secure element, and therequest is a command causing the computing device to retrieve the deviceinformation from the secure element, receiving at least a set of keysfrom the server, wherein the keys are generated in the server inaccordance with the device information of the secure element, andstoring the set of keys in the secure element to facilitate a subsequenttransaction by the computing device.

According to another embodiment, the present invention is a method forpersonalizing a secure element associated with a computing device. Themethod comprises receiving an inquiry to establish data communicationbetween a server and the computing device, sending a request from theserver to the computing device to request device information of thesecure element after the server determines that the computing device isregistered therewith, wherein the device information is a sequence ofcharacters uniquely identifying the secure element, and the request is acommand that subsequently causes the computing device to retrieve thedevice information from the secure element therein, generating at leasta set of keys in accordance with the device information received,delivering the set of keys through a secured channel over a data networkto the computing device, wherein the set of keys is caused to be storedin the secure element with the computing device, and notifying at leasta related party that the secure element is now personalized forsubsequent trusted transactions.

According to still another embodiment, the present invention is a methodfor provisioning an application installed in a mobile device, the methodcomprises sending to a server an identifier identifying the applicationtogether with device information of a secure element associated with amobile device on which the application has been installed, establishinga secured channel between the secure element and the server using a setof key set installed in the secure element, receiving data prepared bythe server to enable the application to function as designed on themobile device; and sending out an acknowledgement to a provider of theapplication about a status of the application now being active with thesecure element on the mobile device. The data received in the mobiledevice includes a user interface of the application per the mobiledevice and a generated application key set.

According to still another embodiment, the present invention is a methodfor provisioning an application, the method comprises receiving from amobile device an identifier identifying the application together withdevice information of a secure element associated with the mobile deviceon which the application has been installed, establishing a securedchannel between the secure element and the server using a set of key setinstalled on the secure element, preparing data necessary for theapplication to function as designed on the mobile device, transportingthe data from the server to enable the application via the securedchannel; and notifying a provider of the application about a status ofthe application now active with the secure element on the mobile device.

According to yet another embodiment, the present invention is a mobiledevice for conducting a transaction over a network, the mobile devicecomprises a network interface, a secure element, a memory space forstoring at least a module and an application downloaded from thenetwork, a processor coupled to the memory space and configured toexecute the module to cause operations including verifying whether theapplication has been provisioned. When it is verified that theapplication has not been provisioned, the operations further comprisesending to a server via the network interface an identifier identifyingthe application together with device information of a secure element,establishing a secured channel between the secure element and the serverusing a key set installed on the secure element, wherein the server isconfigured to prepare data necessary for the application to function asdesigned on the mobile device, receiving the data from the server toassociate the application with the secure element, and sending out anacknowledgement to a provider of the application about a status of theapplication that is now active with the secure element. The processor isfurther configured to determine if the secure element has beenpersonalized before performing a provisioning process of theapplication. If the secure element has not been personalized, the mobiledevice is caused to personalize the secure element with a designedserver.

One of the objects, features, and advantages of the present invention isto enable a mobile device that can be used to perform a securedtransaction with a party (e.g., at a point of sale, with a commercialserver or accessing remotely) over an unsecured network (e.g., theInternet).

Other objects, features, and advantages of the present invention, whichwill become apparent upon examining the following detailed descriptionof an embodiment thereof, taken in conjunction with the attacheddrawings.

BRIEF DESCRIPTION OF THE DRAWINGS

The invention will be readily understood by the following detaileddescription in conjunction with the accompanying drawings, wherein likereference numerals designate like structural elements, and in which:

FIG. 1A shows a simplified architecture of an NFC-enabled mobile devicewith a secure element (SE);

FIG. 1B shows a flowchart or process of personalizing an SE according toone embodiment of the present invention;

FIG. 1C shows relationships among an SE manufacturer, a TSM admin andthe TSM system for both offline and online modes;

FIG. 1D illustrates data flows among a user for an NFC device (e.g., anNFC mobile phone), the NFC device itself, a TSM server, a correspondingSE manufacturer and an SE issuer;

FIG. 1E shows a data flowchart or process of personalizing data flowamong three entities: a land-based SAM or a network e-purse server, ane-purse acting as a gatekeeper, and a single function tag, according toone embodiment;

FIG. 2A shows a mobile payment ecosystem in which related parties areshown in order for the mobile payment ecosystem successful;

FIG. 2B shows a flowchart or process of provisioning one or moreapplications according to one embodiment;

FIG. 2C shows a data flow illustrating various interactions amongdifferent parties when an application is being provisioned in oneembodiment;

FIG. 2D shows a data flow among different entities when preparing theapplication data in provisioning an application;

FIG. 2E shows a flowchart or process for locking or disabling aninstalled application;

FIG. 2F shows an exemplary architecture diagram of a portable deviceenabled as an e-purse conducting e-commerce and m-commerce, according toone embodiment of the present invention;

FIG. 3A is a block diagram of related modules interacting with eachother to achieve what is referred to herein as e-purse personalizationby an authorized personnel (a.k.a., personalizing a mobile device or asecure element therein while provisioning an application);

FIG. 3B shows a block diagram of related modules interacting with eachother to achieve what is referred to herein as e-purse personalizationby a user of the e-purse;

FIG. 3C shows a flowchart or process of personalizing an e-purseaccording to one embodiment of the present invention;

FIG. 4A and FIG. 4B show together a flowchart or process of financing,funding, load or top-up an e-purse according to one embodiment of thepresent invention;

FIG. 4C shows an exemplary block diagram of related blocks interactingwith each other to achieve the process FIG. 4A and FIG. 4B;

FIG. 5A is a diagram showing a first exemplary architecture of aportable device for enabling e-commerce and m-commerce functionalitiesover a cellular communications network (i.e., 3G, LTE or GPRS network),according an embodiment of the present invention;

FIG. 5B is a diagram showing a second exemplary architecture of aportable device for enabling e-commerce and m-commerce functionalitiesover a wired and/or wireless data network (e.g., Internet), accordinganother embodiment of the present invention;

FIG. 5C is a flowchart illustrating an exemplary process of enabling theportable device of FIG. 5A for services/applications provided by one ormore service providers in accordance with one embodiment of the presentinvention;

FIG. 6A is a diagram showing an exemplary architecture, in which aportable device is enabled as a mobile POS conducting e-commerce andm-commerce, according to one embodiment of the present invention;

FIG. 6B is a diagram showing an exemplary architecture, in which aportable device is enabled as a mobile POS conducting a transactionupload operation over a network, according to an embodiment of thepresent invention;

FIG. 6C is a flowchart illustrating an exemplary process of conductingm-commerce using the portable device enabled as a mobile POS with ane-token enabled device as a single functional card in accordance withone embodiment of the present invention;

FIG. 6D is a flowchart illustrating an exemplary process of conductingm-commerce using the portable device enabled as a mobile POS against aan e-token enabled device as a multi-functional card; and

FIG. 7 is a diagram depicting an exemplary configuration in which aportable device used for an e-ticking application.

DETAILED DESCRIPTION OF THE INVENTION

In the following description, numerous specific details are set forth toprovide a thorough understanding of the present invention. The presentinvention may be practiced without these specific details. Thedescription and representation herein are the means used by thoseexperienced or skilled in the art to effectively convey the substance oftheir work to others skilled in the art. In other instances, well-knownmethods, procedures, components, and circuitry have not been describedin detail since they are already well understood and to avoidunnecessarily obscuring aspects of the present invention.

Reference herein to “one embodiment” or “an embodiment” means that aparticular feature, structure, or characteristic described in connectionwith the embodiment can be included in at least one implementation ofthe invention. The appearances of the phrase “in one embodiment” invarious places in the specification are not necessarily all referring tothe same embodiment, nor are separate or alternative embodimentsmutually exclusive of other embodiments. Further, the order of blocks inprocess, flowcharts or functional diagrams representing one or moreembodiments do not inherently indicate any particular order nor implylimitations in the invention.

Embodiments of the present invention are discussed herein with referenceto FIGS. 1A-7. However, those skilled in the art will readily appreciatethat the detailed description given herein with respect to these figuresis for explanatory purposes only as the invention extends beyond theselimited embodiments.

Near Field Communication (NFC) presents significant businessopportunities when used in mobile phones for applications such aspayment, transport ticketing, loyalty, physical access control, andother exciting new services. To support this fast evolving businessenvironment, several entities including financial institutions,manufactures of various NFC-enabled mobile phones and softwaredevelopers, in addition to Mobile Network Operators (MNO), becomeinvolved in the NFC mobile ecosystem. By nature of their individualroles, these players need to communicate with each other and exchangemessages in a reliable and interoperable way.

Equally important to these entities or players, is the need for ongoingsecurity and confidentiality of sensitive applications and datadownloaded to and stored on an NFC enabled handset for performingcontactless transactions. The component in a mobile phone providing thesecurity and confidentiality required to support various business modelsin this environment, is referred to as a Secure Element (SE).

FIG. 1A shows a simplified architecture of a computing device 100.Unless otherwise explicitly indicated, the term of “computing device”,“mobile device” or “handset” will be interchangeably used herein, butthose skilled in the art will understand the description herein shall beequally applicable to other devices such as a smart phone, a tablet, alaptop computer, a contactless smart card and other portable device.

The mobile device 100 includes a near field communication (NFC)controller 101 that enables the device 100 to interact with anotherdevice wirelessly to exchange data with. For example, a user may use themobile device 100 as an e-purse or a wallet to pay for a purchase or anadmission. In operation, the e-purse is controlled by a secure element(SE) 102. Essentially, the SE 102 enables such a mobile device 100 toperform a financial transaction, transport ticketing, loyalty, physicalaccess control, and other exciting new services in a secured manner. Tooffer such services, the SE 102 is configured to support variousapplets, applications or modules (only two samples 104 and 106 are shownin FIG. 1A). Depending on implementation, these modules may be hardwaremodules embedded or inserted thereon, or software modules downloadablefrom one or more servers via a data network.

When a mobile device is first purchased by or delivered to a customer,the SE 102 in the mobile device is installed with a set of default keys(e.g., an Issuer Security Domain (ISD) key set by the SE manufacturer).Depending on implementation, the SE 102 may be in form of a smart card,an integrated circuit (IC) or a software module upgradable byoverwriting some or all of the components therein. In one embodiment,the SE 102 is a tamper proof Smart Card chip capable to embed smartcard-grade applications (e.g., payment, transport . . . ) with therequired level of security and features. In FIG. 1A, the SE 102 embedsor associates with contactless and NFC-related applications and isconnected to the NFC controller 101 to act as the contactless front end.

Typically, a standard-compliant secure element comes with one issuersecurity domain (ISD) and an option for one or more supplementalsecurity domains (SSD). Each of these domains includes a set of keys. Inone embodiment, the SE 102 is a chip embedded in the mobile device 100or in a miniature card inserted into the mobile device 100 via a cardinterface 109. In another embodiment, the SE 102 is or includes asoftware module loaded in a secured memory space 107 in the mobiledevice 100. The software module may be updated by downloading updatingcomponents from a designated server using a network interface 103 (e.g.,a 3G network or an LTE network) in the mobile device 100.

The SE 102 needs to go through a personalization process before it canbe used. In one embodiment, the personalization process is to load theSE 102 with or update a key set with a derived personalized key set of achosen card issuer (i.e., a so-called SE issuer). Such a personalizationprocess may be also referred to as a provisioning process. According toone embodiment, the provisioning is performed over the air (OTA) tocause the SE to be personalized while installing an application orenabling a service (i.e., application installation and personalization).The personalization of an SE is only done once to associate the SE to anSE issuer. The application installation and provisioning shall be donefor each application when a user subscribes or installs an application.

In one embodiment, when updating or upgrading the SE 102, only one orsome components pertaining to the SE 102 are replaced by newer updatesto avoid personalizing the SE 102 from beginning. Depending onimplementation, such newer updates may be automatically or manuallyobtained to be loaded into the mobile device 100.

In one embodiment, applications are available for an NFC-enabled mobiledevice to download from a server or a TSM portal depending on thecorresponding SE issuer and the TSM thereof. TSM, standing for TrustedService Management, is a collection of services. One main role envisagedfor the TSM is to help service providers securely distribute and managecontactless services for their customers using the networks of mobileoperators. The TSM or its server(s) does not necessarily participate inactual contactless transactions using NFC devices. These transactionsare processed normally in whatever system the service provider and itsmerchant partners have already put in place. Another role of the TSM isto accelerate the successful deployment and ramp-up of mobile NFCapplications by acting as a commercial intermediary that facilitatescontractual arrangements and other aspects of ongoing businessrelationships among different parties that make the commerce via themobile networks possible.

The personalization process can be done either physically in a servicecenter or remotely via a web portal by a TSM server. In the firstscenario, the customer may physically go to a service center to let aservice representative to personalize the SE in a mobile device. With acomputer connected to an NFC reader at a designated place (e.g., aservice center), a provisioning manager can be either an installedapplication or a web-based application connecting to a backend TSM. Theprovisioning manager is configured to communicate with the SE of themobile device (e.g., via a reader). Such a personalization process isreferred to as a process Over the Internet (OTI).

In the second scenario, the customer registers his/her mobile phone viaa server (often a TSM web portal). The TSM server is configured to pusha universal resource identifier (URI) of a provisioning manager to theregistered mobile phone. Depending on a type of the device, the push canbe either an SMS (Short Message Service) Push or a Google Android Push.The customer can download the provisioning manager into the mobiledevice and start the personalization process. Such a personalizationprocess is referred to as a process Over the Air (OTA).

In either one of the scenarios, the provisioning manager acts as a proxybetween the SE in the mobile device and the TSM server. Referring now toFIG. 1B, it shows a flowchart or process 110 of personalizing an SEaccording to one embodiment of the present invention. Depending onimplementation, the process 110 may be implemented in software or acombination of software and hardware. When a user receives a new NFCdevice (e.g., a part of a mobile device), the SE therein needs to bepersonalized.

At 112, the new NFC device is determined if it is a genuine NFC device.One example is to check a serial number associated with the NFC device.The serial number may be verified with a database associated with a TSMserver. In the example of a NFC mobile device, the device serial numberof the mobile device may be used for verification. It is now assumedthat the NFC device is a genuine device (recognizable by a mobileoperator). The process 110 goes to 114 to have the NFC devicecommunicated with a dedicated server. In one embodiment, the server is apart of the Trusted Service Management (TSM) system and accessible by awireless network, the Internet or a combination of wireless and wirednetworks (herein referred to as a data network or simply a network).

At 116, the NFC device is registered with the server. Once the NFCdevice becomes part of the system, various services or data may becommunicated to the device via the network. As part of thepersonalization process, the server requests device information of theSE at 118. In one embodiment, the server is configured to send a datarequest (e.g., a WAP PUSH) to the device. In responding to the request,the device sends back CPLC (card product life cycle) informationretrieved from the SE. The CPLC includes the SE product information(e.g., the smart card ID, manufacturer information and a batch numberand etc.). Based on the CPLC info, the server is able to retrievecorresponding default Issuer Security Domain (ISD) information of thisSE from its manufacturer, an authorized distributor or a serviceprovider (referred to as a manufacturer, a distributor or a provider ofthe SE). Depending on implementation, there are two ways that the servermay communicate with a SE manufacturer, which will be fully discussedherein late when deemed appropriate.

At 120, it is up to the manufacturer whether to update the deviceinformation. In general, when an SE is shipped from the manufacturer,the SE is embedded with some default device information. If it isdecided that the default information such as the CPLC data is to beupdated with the manufacturer, the process 110 goes to 122 where themanufacturer uploads corresponding updated device information to theserver. The updated device information is transported to the device andstored in the SE at 124. If it is decided that the default informationin the SE is not to be updated with the manufacturer, the process 110goes to 124 to store the retrieved default device information in adatabase with the TSM server. In one embodiment, the server isconfigured to include an interface to retrieve a derived SE key set. Inone embodiment, the derived key set is generated with the deviceinformation (e.g., ISD) of the SE. When the derived ISD key set issuccessfully installed on the SE, the corresponding SE issuer isnotified of the use of the derived ISD key set.

According to one embodiment, the device information (default or updated)is used to facilitate the generation of a set of keys at 126. In oneembodiment, the server is configured to establish a secured channelusing the default ISD between its hardware security module (HSM) and theSE. The server is also configured to compute a derived key set for theSE. Depending on a business agreement, a master ISD key of an issuer forthe SE may be housed in a hardware security module (HSM) associated withthe server or in a local HSM of the SE issuer. An HSM is a type ofsecure crypto-processor targeted at managing digital keys, acceleratingcrypto-processes in terms of digital signings/second and for providingstrong authentication to access critical keys for server applications.If it is housed in the HSM of the server, the server is configured toinstruct the HSM to compute the derived key set. Then, the serverprepares a mechanism (e.g., PUT KEY APDU) and uses the default channelto replace the default key set in the SE with the derived key set. Ifthe master ISD key of the SE issuer is in a local HSM of the SE issuer,the server is configured to interact with the remote HSM to retrieve thekeys.

At 128, the set of keys is securely delivered to the SE. The set of keysis thus personalized to the SE and will be used for various securedsubsequent operations or services with the NFC device. The server at 130is configured to synchronize the SE with the issuer or provider (e.g.,sending a notification thereto about the status of the SE).

After the personalization, the SE can only be accessed using thepersonalized ISD key of the SE issuer. Depending on the securityrequirement of each service provider, the TSM can create additional SSDsfor the various providers to personalize their respective applications(e.g., the modules 104 or 106 of FIG. 1A).

As mentioned above, there are two ways that may be used to retrieve thecorresponding default Issuer Security Domain (ISD) information from theSE in interfacing with the manufacturer thereof. Depending on theinfrastructure, a manufacturer can choose to use a real-time approach ora batch approach.

In the real-time approach, the server is configured to communicate withthe manufacturer (i.e., its server thereof) when an SE by themanufacturer is being personalized by the TSM server. The default keyset is, thus, retrieved on demand from the server of the manufacturer.In one embodiment, the TSM server includes a plugin module for each ofthe manufacturers to communicate therewith.

In the batch approach, it can be done either offline mode or onlinemode. In the offline mode, the SE manufacturer delivers the default ISDinformation for all SEs being supported via an encrypted physical media.An administrator for the TSM may or a computing device may be configuredto import the information in the media to a computing device. Thedefault ISDs are then decrypted and retrieved, and stored in a database.In the online mode, the SE manufacturer uploads the default ISDinformation for the SEs it supports via a network. The default ISDs arethen decrypted and retrieved, and stored in a database. Afterwards, theTSM only needs to access its own HSM o the database during an SEpersonalization process. FIG. 1C shows relationships among the SEmanufacturer, the TSM admin and the TSM system for both offline andonline modes.

According to one embodiment of the present invention, FIG. 1Dillustrates data flows among a user for an NFC device (e.g., an NFCmobile phone), the NFC device itself, a TSM server, a corresponding SEmanufacturer and an SE issuer.

In one perspective, the SE 102 of FIG. 1A may be perceived as a preloadoperating system in a smart card, providing a platform for PINmanagement and security channels (security domains) for cardpersonalization. The SE 102 combines the interests of smart cardissuers, vendors, industry groups, public entities and technologycompanies to define requirements and technology standards for multipleapplications running in the smart cards.

As an example, one module 104 referred to as an e-purse security definesa set of protocols that enable micro payment transactions to be carriedout in both wired and wireless environments. With an electronic purse(a.k.a., e-purse) stored on a smart card, a set of keys (eithersymmetric or asymmetric) is personalized into the e-purse after thee-purse is issued. During a transaction, the e-purse uses a set ofrespective keys for encryption and MAC computation in order to securethe message channel between the e-purse and an SAM (SecurityAuthentication Module) or backend servers. For a single functional card,the e-purse security 104 is configured to act as gates to protect actualoperations performed on a single functional card. Duringpersonalization, the single functional card access keys (or itstransformation) are personalized into the e-purse with the e-pursetransaction keys.

FIG. 1E shows a flowchart or process 150 of personalizing data flowamong three entities: a land-based SAM or a network e-purse server 152,an e-purse 154 acting as a gatekeeper, and a single function tag 156.Communications between the land-based SAM or the network e-purse server152 and the e-purse 154 are conducted in sequence of a type of commands(e.g., APDU) while communications between the e-purse 154 and the singlefunction tag 156 are conducted in sequence of another type of commands,wherein the e-purse 154 acts as the gate keeper to ensure only securedand authorized data transactions could happen.

In one embodiment, the physical security for the e-purse is realized inan emulator. As used herein, an emulator means a hardware device or aprogram that pretends to be another particular device or program thatother components expect to interact with. The e-purse security isrealized between one or more applets configured to provide e-pursefunctioning and communication with a payment server. An SE supportingthe e-purse is responsible for updating security keys to establishappropriate channels for interactions between a payment server and theapplets, wherein the e-purse applet(s) acts as a gatekeeper to regulateor control the data exchange.

Referring now to FIG. 2A, it shows a mobile payment ecosystem 200 inwhich related parties are involved in order for the mobile paymentecosystem successful. According to one embodiment, an NFC device isallowed to install or download one or more applications from respectivedesignated servers 202 (i.e., application management providers), wherethe applications are originally developed by developers 204 anddistributed by service providers 210, application management providers202 or others. It is assumed that the secure element 206 provided by asecure element provider 208 has already been personalized via a TSM or atrusted third party (e.g., a financial institution 212).

Once an application is installed in the NFC device, the next step is toprovision the application with the secure element. An applicationprovisioning process can be started in several ways. One of the ways isthat an SE holder selects an application from a TSM portal on the mobiledevice and initiates the provisioning process. Another one is that theSE holder receives an application provisioning notification on themobile device from the TSM on behalf of an application (service)provider.

The TSM or application providers can publish their applications on a TSMportal to be downloaded to a mobile device with the SE and/or subscribedat a request of a user (a.k.a., an SE holder). In one embodiment, theTSM is a cloud service to serve many SE issuers. Thus, many applicationsfrom various service providers are available on the TSM portal. However,when getting onto the TSM portal, SE holders can only see thoseapplications approved by its SE issuer. Depending on the arrangementbetween an SE and a service provider, an application can either bedownloaded/installed/personalized using the ISD keyset of the SE or aspecific SSD keyset of the service provider. If a SSD keyset has notbeen installed on the SE, it can be installed during an applicationinstallation.

The TSM knows the memory state of an SE for various SSDs. Based on thestate of the SE and the memory allocation policy of the SSDs, theavailable applications for the various SSD in the application store maybe marked with different indicators, for example, “OK to install”, or“Insufficient memory to install”. This will prevent unnecessary failurefor users.

Once an application is installed on an NFC device, the applicationinitiates a provisioning process by itself, or the TSM can push aprovisioning notification to the NFC device via a cellular network or awireless data network. Depending on the type of the devices, there aremany different types of push messages to cause the NFC device to initialthe provision process. An example of the push methods includes an SMSpush or an Android Google Push. Once user accepts the notification, theprovisioning process starts. The details of the provisioning processwill be described below whenever deemed appropriate.

As part of the application provisioning, a TSM server implements someprotective mechanism. One is to prevent an SE from being accidentallylocked. Another is to disable application download if there is nosufficient memory on SE.

An SE may permanently lock itself if there are too many failed mutualauthentications during secure channel establishment. In order to preventthe SE from being accidentally locked, the TSM keeps the track of thenumber of failed authentications between an SE and the TSM whenestablishing a secured channel between the two entities. In oneembodiment, the TSM is configured to reject any further request if apreset limit is reached. The TSM can continue to process the SE requestif the SE is reset at the service center manually.

The TSM also keeps track of the memory usage of each SE. The TSM decideswhether an application can be installed on an SE based on the memoryallocation assigned by the SE issuer to each service provider. Accordingone embodiment, there are three types of policies:

-   -   Pre-assigned a fixed memory. This is the guaranteed space.    -   Pre-assigned a minimum memory. This is the guaranteed minimum        space.    -   Best efforts.

The SE issuer uses the TSM web portal to make this assignment.

-   -   1. For a batch of SE, the SE issuer can pre-assign a memory        policy for a service provider to install its applications via        the TSM web portal;    -   2. The TSM server verifies whether the space of the respective        service provider conforms to its policy when a Mobile Device        requests to install one of its applications. If not conformed,        this request is rejected;    -   3. Otherwise, the TSM server will proceed to handle the        provisioning request;    -   4. If the provisioning succeeds, the TSM will accumulate the        memory size of this application service.

When a mobile user subscribes to a mobile application (assuming it hasbeen installed), the application has to be provisioned with the SE inthe mobile device before it can be used. According to one embodiment,the provisioning process includes four major stages:

-   -   Create an supplemental security domain (SSD) on the SE, if        needed;    -   Download and install an application cap on the SE;    -   Personalize the application on the SE; and    -   Download a UI component on mobile phone.

FIG. 2B shows a flowchart or process 220 of provisioning one or moreapplications according to one embodiment. The process 220 may beimplemented in software or a combination of software and hardware. Inone embodiment, the application provisioning process 220 needs to gothrough a provisioning manager (i.e., proxy) on the mobile phone tointeract with the SE therein.

As shown in FIG. 2B, at 222, the application provisioning process 220may be started manually or automatically. For example, a user mayinitiate the process 220 by selecting an installed application tosubscribe related services or the installed application, when activated,initiates the provisioning process, provided it has not beenprovisioned. In another embodiment, a provider of an application pushesa message (e.g., SMS) to the mobile phone to initiate the provisioningprocess.

In any case, the process 220 goes to 224 to establish a communicationwith a dedicated server (e.g., a TSM server or a server operated by anapplication distributor) after the device information (e.g., CPLC) isretrieved from the SE in the mobile device. The device information alongwith an identifier identifying the application is transmitted to theserver at 226. Based on the device information, the server identifiesthe issuer for the SE first at 228 to determine if the SE has beenpersonalized at 230. If the SE has not been personalized, the process220 goes to 232 to personalize the SE, where one embodiment of thefunction 232 may be implemented in accordance with the process 110 ofFIG. 1B.

It is now assumed that the SE in the mobile device has beenpersonalized. The process 220 now goes to 234 to establish a securechannel with the SE using the derived ISD. Depending on who houses theHSM (TSM or SE issuer) for the ISD, the server will contact the HSM tocompute the derived ISD for the SE and establish a secure channel withthe SE using this derived ISD. The server is then configured to check tosee whether there is an SSD associated with this application at 236. Ifthere is not an SSD associated with the application, the server isconfigured to check a database to see whether it has been installed withthis SE. If the SSD installation is needed, then the process 220 goes toinstall the SSD. In one embodiment, the user is alerted of theinstallation of the SSD (keys). Should the user refuse to install theSSD at 238, the process 220 stops and goes to 222 to restart theprovisioning process 220.

It is now assumed that the process of installing the SSD proceeds at240. Installing the SSD is similar to installing the ISD. The TSM serveris configured to contact the HSM that houses the SSD master key tocompute the derived SSD key set for the SE. The master SSD key set canbe either in the TSM or with the service provider or the SE issuer,largely depending on how the arrangement is made with all partiesinvolved.

To download/install the application cap to the SE, the server isconfigured to establish a secure channel with the SE using this derivedSSD at 242. In one embodiment, this is similar to how the ISD-basedsecure channel is established. At 244, the data for the application isprepared, the detail of which will be further discussed below. Accordingto one embodiment, the server is configured to contact the serviceprovider to prepare STORE DATA APDUs. Depending on an applicationinstalled in a mobile device, the server may be caused to repeatedlyissue STORE DATA to personalize the application with the SE. Additionaldata including an appropriate interface (e.g., a user interface of theapplication per the mobile device) may be downloaded provided that theprovisioning process is successfully done. At 246, the server willnotify the application provider the status of the application that hasbeen provisioned.

FIG. 2C shows a data flow 250 illustrating various interactions amongdifferent parties when an application is being provisioned in oneembodiment.

As shown in 244 of FIG. 2B, one of the important functions inprovisioning an application is to prepare customized application datafor the targeted SE. For example, for an e-purse application, thepersonalized data for the application includes various personalizedtransaction keys generated based on the device information (e.g., CPLCinfo) of the SE. For transit e-purse, part of the personalized dataincludes the Mifare access keys derived from an identifier (ID) of theMifare card, the server is configured to personalize both Java Cardapplications and Mifare4Mobile service objects. In general, there are atleast two different ways to prepare the data to facilitate subsequenttransactions.

For data preparation, one embodiment of the present invention supportstwo operation modes to interact with service providers for computing thepersonalized application data. For the first mode, a TSM server does nothave direct access to the HSM associated with a service provider. Theservice provider may have a server interacting with its HSM to generatethe application keys (e.g., Transit, e-purse, or Mifare Key). The TSMdata preparation implementation is to make use of application programinterfaces (API) or a protocol provided by the server to request forderived application keys. The second mode is that data preparationimplementation can directly access the HSM associated with the serviceprovider to generate the application keys.

According to one embodiment, FIG. 2D shows a data flow 255 amongdifferent entities when preparing the application data in provisioningan application. FIG. 2D is provided for the first mode in which a TSMserver does not have direct access to the HSM associated with a serviceprovide. The second mode has the similar flow except that theapplication data preparation implementation will interact directly withthe HSM of a service provider.

Besides supporting a provisioning process, one embodiment of the presentinvention also supports the life cycle management of an SE. The lifecycle management includes, but may not be limited to, SE lock, SEunlock, Application Delete (disabling). The initiation of theseactivities may be through a TSM push notification. In actual use ofmobile devices, FIG. 2E shows a flowchart or process 260 of locking aninstalled application. An NFC device may have been installed with anumber of applications in connection with or running on top of thesecured element therein. For some reason (e.g., no activity for aprolonged period or expiration), an application needs to be disabled orlocked by its distributor or provider.

The operation or process 260 to disable an installed application isinitiated at 262. In one embodiment, the process 260 is initiated by anoperator manually via a TSM web portal. In another embodiment, theprocess 260 is automatically initiated by a service provider internalworkflow (e.g., using TSM web service API). Once the process 260 isinitiated, a message is pushed to a NFC device (e.g., within a mobiledevice) in which an application is to be disabled. Depending onapplication, such a message may come in different forms. In oneembodiment, the message is a PUSH command. In another embodiment, themessage is a TCP/IP request delivered to the device via a network. Themessage may be sent from a server (e.g., a TSM server) at 264. Dependingon implementation, such a message may include an identifier identifyingan application to be locked or disabled. Upon receiving such a message,a card manager proxy on the device is caused to verify whether such amessage is indeed from its original distributor or provider by returninga message at 266. According to one embodiment, the message is sent to aTSM server for verification. If the verification fails, namely there isno acknowledgement to such an inquiry, the process 260 is abandoned.

It is now assumed that the verification is successful, namely theinquiry from the device to a provider of the application returns anacknowledgement that the original request is authenticated. In general,such an acknowledgement includes an identifier confirming theapplication to be locked at 268. The TSM server is configured toestablish a secure channel with the SE as described previously. Then,the TSM server is to prepare appropriate APDUs (such as SET STATUS,or/and DELETE) for the SE for execution via the card manager proxy.

In any case, in responding to the command, the SE proceeds by lockingthe application at 272. According to one embodiment, the SE is caused todisassociate with the application, thus making the installed applicationno longer usable with the SE. At 274, the SE is configured to send outan acknowledgement to notify related parties that this application is nolonger operating in the device. In one embodiment, the acknowledgementis sent over to the TSM server where there is a database recording whatapplications have been installed in what device, and a correspondingstatus of each. The database is updated with the acknowledgement fromthe SE.

FIG. 2E shows a flowchart or process for locking or disabling aninstalled application. It is known to those skilled in the art thatother operations, such as unlocking or enabling an installedapplication, extending expiration of an installed application, aresimilar to those shown in FIG. 2E.

Referring now to FIG. 2F, there shows an exemplary architecture diagram280 of a portable device enabled as an electronic wallet or e-purse tofacilitate e-commerce and m-commerce, according to one embodiment of thepresent invention. The diagram 280 includes a cell phone 282 embeddedwith a smart card module. An example of such a cell phone is a nearfield communication (NFC) enabled cellphone that includes a Smart MX(SMX) module. It shall be noted that a secure element and an applicationmay be integrated. Unless explicitly stated, the following descriptionwill not call out which part is performing the function of a secureelement and which part is performing as a application. Those skilled inthe art shall appreciate the proper parts or functions being performedgiven the detailed description herein.

The SMX is pre-loaded with a Mifare emulator 288 (which is a singlefunctional card) for storing values. The cell phone is equipped with acontactless interface (e.g., ISO 14443 RFID) that allows the cell phoneto act as a tag. In addition, the SMX is a JavaCard that can run Javaapplets. According to one embodiment, an e-purse is built as an appletin SMX. The e-purse is configured to be able to access the Mifare datastructures with appropriate transformed passwords based on the accesskeys.

In the cell phone 282, an e-purse manager MIDlet 204 is provided. Form-commerce, the MIDlet 284 acts as an agent to facilitate communicationsbetween an e-purse applet 286 and one or more payment network andservers 290 to conduct transactions therebetween. As used herein, aMIDlet is a software component suitable for being executed on a portabledevice. The e-purse manager MIDlet 284 is implemented as a “MIDlet” on aJava cell phone, or an “executable application” on a PDA device. One ofthe functions of the e-purse manager MIDlet 284 is to connect to awireless network and communicate with an e-purse applet which can resideon either the same device or an external smart card. In addition, it isconfigured to provide administrative functions such as changing a PIN,viewing an e-purse balance and a transaction history log. In oneapplication in which a card issuer provides a SAM 292 that is used toenable and authenticate any transactions between a card and acorresponding server (also referred to as a payment server). As shown inFIG. 2F, APDU commands are constructed by the servers 290 having accessto a SAM 292, where the APDU is a communication unit between a readerand a card. The structure of an APDU is defined by the ISO 7816standards. Typically, an APDU command is embedded in network messagesand delivered to the server 290 or the e-purse applet 286 forprocessing.

For e-commerce, a web agent 294 on a computer (not shown) is responsiblefor interacting with a contactless reader (e.g., an ISO 14443 RFIDreader) and the network server 290. In operation, the agent 294 sendsthe APDU commands or receives responses thereto through the contactlessreader 296 to/from the e-purse applet 286 residing in the cell phone282. On the other hand, the agent 294 composes network requests (such asHTTP) and receives responses thereto from the payment server 280.

To personalize the cell phone 282, FIG. 3A shows a block diagram 300 ofrelated modules interacting with each other to achieve what is referredto herein as e-purse personalization (or provisioning) by an authorizedperson. FIG. 3B shows a block diagram 320 of related modules interactingwith each other to achieve what is referred to herein as e-pursepersonalization by a user of the e-purse as shown in FIG. 2F.

FIG. 3C shows a flowchart or process 350 of personalizing an e-purseapplet according to one embodiment of the present invention. FIG. 3C issuggested to be understood in conjunction with FIG. 3A and FIG. 3B. Theprocess 350 may be implemented in software, hardware or a combination ofboth.

As described above, an e-purse manager is built on top of a globalplatform to provide a security mechanism necessary to personalizee-purse applets designed therefor. In operation, a security domain isused for establishing a secured channel between a personalizationapplication server and the e-purse applet. According to one embodiment,the essential data to be personalized into the e-purse applet includeone or more operation keys (e.g., a load or top-up key and a purchasekey), default PINs, administration keys (e.g., an unblock PIN key and areload PIN key), and passwords (e.g., from Mifare).

It is assumed that a user desires to personalize an e-purse appletembedded in a portable device (e.g., a cell phone). At 352 of FIG. 3C, apersonalization process is initiated. Depending on implementation, thepersonalization process may be implemented in a module in the portabledevice and activated manually or automatically, or a physical processinitiated by an authorized person (typically associated with a cardissuer). As shown in FIG. 3A, an authorized personal initiates apersonalization process 304 to personalize the e-purse applet for a userthereof via an existing new e-purse SAM 306 and an existing SAM 308 withthe contactless reader 310 as the interface. The card manager 311performs at least two functions: 1) establishing a security channel, viaa security domain, to install and personalize an external application(e.g., e-purse applet) in the card personalization; and 2) creatingsecurity means (e.g., PINs) to protect the application during subsequentoperations. As a result of the personalization process using thepersonalization application server 304, the e-purse applet 312 and theemulator 314 are personalized.

Similarly, as shown in FIG. 3B, a user of an e-purse desires to initiatea personalization process to personalize the e-purse applet wirelessly(e.g., via the m-commerce path of FIG. 2). Different from FIG. 3A, FIG.3B allows the personalization process to be activated manually orautomatically. For example, there is a mechanism on a cell phone that,if pressed, activates the personalization process. Alternatively, astatus of “non-personalized” may prompt to the user to start thepersonalization process. As described above, a MIDlet 322 (i.e., aprovisioning manager or a service manager) in a portable device acts asan agent to facilitate the communication between a payment server 324and the e-purse applet 312 as well as the emulator 314, wherein thepayment server 324 has the access to the existing new e-purse SAM 306and an existing SAM 308. As a result of the personalization process, thee-purse applet 312 and the emulator 314 are personalized.

Referring now back to FIG. 3C, after the personalization process isstarted, in view of FIG. 3A, the contactless reader 310 is activated toread the tag ID (i.e., RFID tag ID) and essential data from a smart cardin the device at 354. With an application security domain (e.g., adefault security setting by a card issuer), a security channel is thenestablished at 356 between a new e-purse SAM (e.g., the SAM 306 of FIG.3A) and an e-purse applet (e.g., the e-purse applet 312 of FIG. 3A) inthe portable device.

Each application security domain key set includes at least three (3) DESkeys. For example:

Key1: 255/1/DES-ECB/404142434445464748494a4b4c4d4e4f

Key2: 255/2/DES-ECB/404142434445464748494a4b4c4d4e4f

Key3: 255/3/DES-ECB/404142434445464748494a4b4c4d4e4f

A security domain is used to generate session keys for a secured sessionbetween two entities, such as the card manager applet and a hostapplication, in which case the host application may be either a desktoppersonalization application or a networked personalization serviceprovided by a backend server.

A default application domain can be installed by a card issuer andassigned to various application/service providers. The respectiveapplication owner can change the value of the key sets before thepersonalization process (or at the initial of the process). Then theapplication can use the new set to create a security channel forperforming the personalization process.

With the security channel is established using the applicationprovider's application security domain, the first set of data can bepersonalized to the e-purse applet. The second set of data can also bepersonalized with the same channel, too. However, if the data are inseparate SAM, then a new security channel with the same key set (ordifferent key sets) can be used to personalize the second set of data.

Via the new e-purse SAM 306, a set of e-purse operation keys and PINsare generated for data transactions between the new e-purse SAM and thee-purse applet to essentially personalize the e-purse applet at 358.

A second security channel is then established at 360 between an existingSAM (e.g., the SAM 308 of FIG. 3A) and the e-purse applet (e.g., thee-purse applet 312 of FIG. 3A) in the portable device. At 362, a set oftransformed keys is generated using the existing SAM and the tag ID. Thegenerated keys are stored in the emulator for subsequent data accessauthentication. At 358, a set of MF passwords is generated using theexisting SAM and the tag ID, then is stored into the e-purse applet forfuture data access authentication. After it is done, the e-purseincluding the e-purse applet and the corresponding emulator is set to astate of “personalized”.

FIG. 4A and FIG. 4B show together a flowchart or process 400 offinancing or funding an e-purse according to one embodiment of thepresent invention. The process 400 is conducted via the m-commerce pathof FIG. 2. To better understand the process 400, FIG. 4C shows anexemplary block diagram 450 of related blocks interacting with eachother to achieve the process 400. Depending on an actual application ofthe present invention, the process 400 may be implemented in software,hardware or a combination of both.

A user is assumed to have obtained a portable device (e.g., a cellphone) that is configured to include an e-purse. The user desires tofund the e-purse from an account associated with a bank. At 402, theuser enters a set of personal identification numbers (PIN). Assuming thePIN is valid, an e-purse manger in the portable device is activated andinitiates a request (also referred to an over-the-air (OTA) top-uprequest) at 404. The MIDlet in the portable device sends a request tothe e-purse applet at 406, which is illustrated in FIG. 4C where thee-purse manager MIDlet 434 communicates with the e-purse applet 436.

At 408, the e-purse applet composes a response in responding to therequest from the MIDlet. Upon receiving the response, the MIDlet sendsthe response to a payment network and server over a cellularcommunications network. As shown in FIG. 4C, the e-purse manager MIDlet434 communicates with the e-purse applet 436 for a response that is thensent to the payment network and server 440. At 410, the process 400needs to verify the validity of the response. If the response cannot beverified, the process 400 stops. If the response can be verified, theprocess 400 moves to 412 where a corresponding account at a bank isverified. If the account does exist, a fund transfer request isinitiated. At 414, the bank receives the request and responds to therequest by returning a response. In general, the messages exchangedbetween the payment network and server and the bank are compliant with anetwork protocol (e.g., HTTP for the Internet).

At 416, the response from the bank is transported to the payment networkand server. The MIDlet strips and extracts the APDU commands from theresponse and forwards the commands to the e-purse applet at 418. Thee-purse applet verifies the commands at 420 and, provided they areauthorized, sends the commands to the emulator at 420 and, meanwhileupdating a transaction log. At 422, a ticket is generated to formulate aresponse (e.g., in APDU format) for the payment server. As a result, thepayment server is updated with a successful status message for theMIDlet, where the APDU response is retained for subsequent verificationat 424.

As shown in FIG. 4C, the payment network and server 440 receives aresponse from the e-purse manager MIDlet 434 and verifies that theresponse is from an authorized e-purse applet 436 originally issuedtherefrom with a SAM 444. After the response is verified, the paymentnetwork and server 440 sends a request to the financing bank 442 withwhich the user 432 is assumed to maintain an account. The bank willverify the request, authorize the request, and return an authorizationnumber in some pre-arranged message format. Upon receiving the responsefrom the bank 442, the payment server 440 will either reject the requestor accept the request by forming a network response sent to the MIDlet434.

The e-purse manager 434 verifies the authenticity (e.g., in APDU format)and sends commands to the emulator 438 and updates the transaction logs.By now, the e-purse applet 436 finishes the necessary steps and returnsa response to the MIDlet 434 that forwards an (APDU) response in anetwork request to the payment server 440.

Although the process 400 is described as funding the e-purse. Thoseskilled in the art can appreciate that the process of making purchasingover a network with the e-purse is substantially similar to the process400, accordingly no separate discussion on the process of makingpurchasing is provided.

Referring to FIG. 5A, there is shown a first exemplary architecture 500of enabling a portable device 530 for e-commerce and m-commerce over acellular communications network 520 (e.g., a GPRS network) in accordancewith one embodiment of the present invention. The portable device 530comprises a baseband 524 and a secured element 529 (e.g., a smart card).One example of such portable device is a Near Field Communication (NFC)enabled portable device (e.g., a cell mobile phone or a PDA). Thebaseband 524 provides an electronic platform or environment (e.g., aJava Micro Edition (JME), or Mobile Information Device Profile (MIDP)),on which an application MIDlet 523 and a service manager 522 can beexecuted or run. The secured element 529 contains a Global Platform (GP)card manager 526, an emulator 528 and other components such as PINmanager (not shown).

To enable the portable device 530 to conduct e-commerce and m-commerce,one or more services/applications need to be pre-installed andpre-configured thereon. An instance of a service manager 522 (e.g., aMIDlet with GUI) needs to be activated. In one embodiment, the servicemanager 522 is downloaded and installed. In another embodiment, theservice manager 522 is preloaded. In any case, once the service manager522 is activated, a list of directories for various services is shown.The items in the list may be related to the subscription by a user, andmay also include items in promotion independent of the subscription bythe user. The directory list may be received from a directory repository502 of a directory server 512. The directory server 512 acts as acentral hub (i.e., yellow page functions) for different serviceproviders (e.g., an installation server, a personalization server) thatmay choose to offer products and/or services to subscribers. The yellowpage functions of the directory server 512 may include service planinformation (e.g., service charge, start date, end date, etc.),installation, personalization and/or MIDlet download locations (e.g.,Internet addresses). The installation and personalization may beprovided by two different business entities. For example, theinstallation is provided by an issuer of a secured element 529, whilethe personalization may be provided by a service provider who holdsapplication transaction keys for a particular application.

According to one embodiment, the service manager 522 is configured toconnect to one or more servers 514 (e.g., a TSM server) from a serviceprovider(s) over the cellular communications network 520. It is assumedthat the user has chosen one of the applications from the displayeddirectory. A secured channel 518 is established between the one or moreservers 514 and the GP manager 526 to install/download an applicationapplet 527 selected by the user and then to personalize the applicationapplet 527 and optionally emulator 528, and finally to download anapplication MIDlet 523. The applet repository 504 and MIDlet repository506 are the sources of generic application applets and applicationMIDlets, respectively. GP SAM 516 and application SAM 517 are used forcreating the secured channel 518 for the personalization operations.

FIG. 5B is a diagram showing a second exemplary architecture 540 ofenabling a portable device 530 for e-commerce and m-commerce over apublic network 521, according to another embodiment of the presentinvention. Most of the components of the second architecture 540 aresubstantially similar to those of the first architecture 500 of FIG. 5A.While the first architecture 500 is based on operations over a cellularcommunications network 520, the public network 521 (e.g., Internet) isused in the second architecture 540. The public network 521 may includea local area network (LAN), a wide area network (WAN), a Wi-Fi (IEEE802.11) wireless link, a Wi-Max (IEEE 802.16) wireless link, etc. Inorder to conduct service operations over the public network 521, aninstance of the service manager 532 (i.e., same or similar functionalityof the service manager MIDlet 522) is installed on a computer 538, whichis coupled to the public network 521. The computer 538 may be a desktoppersonal computer (PC), a laptop PC, or other computing devices that canexecute the instance of the service manager 532 and be connected to thepublic network 521. The connection between the computer 538 and theportable device 530 is through a contactless reader 534. The servicemanager 532 acts as an agent to facilitate the installation andpersonalization between one or more servers 514 of a service providerand a GP card manager 526 via a secured channel 519.

FIG. 5C is a flowchart illustrating a process 550 of enabling a portabledevice for e-commerce and m-commerce functionalities in accordance withone embodiment of the present invention. The process 550 may beimplemented in software, hardware or a combination of both depending onimplementation. To better understand the process 500, previous figuresespecially FIG. 5A and FIG. 5B are referred to in the followingdescription.

Before the process 550 starts, an instance of a service manager 522 or532 has been downloaded or pre-installed on either the portable device530 or a computer 538. At 552, the service manager is activated andsends a service request to the server 514 at a service provider. Nextafter the authentication of a user and the portable device has beenverified, at 554, the process 550 provides a directory list ofservices/applications based on subscription of the user of the portabledevice 530. For example, the list may contain a mobile POS application,an e-purse application, an e-ticketing application, and othercommercially offered services. Then one of the services/applications ischosen from the directory list. For example, an e-purse or a mobile-POSmay be chosen to configure the portable device 530. Responding to theuser selection, the process 550 downloads and installs the selectedservices/applications at 556. For example, e-purse applet (i.e.,application applet 527) is downloaded from the applet repository 504 andinstalled onto a secured element 529. The path for downloading orinstallation may be either via a secured channel 518 or 519. At 558, theprocess 550 personalizes the downloaded application applet and theemulator 528 if needed. Some of the downloaded application applets donot need to be personalized and some do. In one embodiment, a mobile POSapplication applet (“POS SAM”) needs to be personalized, and thefollowing information or data array has to be provided:

-   -   a unique SAM ID based on the unique identifier of the underlying        secured element;    -   a set of debit master keys;    -   a transformed message encryption key;    -   a transformed message authentication key;    -   a maximum length of remark for each offline transaction;    -   a transformed batch transaction key; and    -   a GP PIN.

In another embodiment, personalization of an e-purse applet for a singlefunctional card not only needs to configure specific data (i.e., PINs,transformed keys, start date, end date, etc.) onto the e-purse, but alsoneeds to configure the emulator to be operable in an open system.Finally, at 560, the process 550 downloads and optionally launches theapplication MIDlet 523. Some of the personalized data from theapplication applet may be accessed and displayed or provided from theuser. The process 550 ends when all of the components ofservices/applications have been installed, personalized and downloaded.

According to one embodiment, an exemplary process of enabling a portabledevice 530 as a mobile POS is listed as follows:

-   -   connecting to an installation server (i.e., one of the service        provider server 514) to request the server to establish a first        security channel (e.g., the secured channel 518) from an issuer        domain (i.e., applet repository 504) to the GP card manager 526        residing in a secured element 529;    -   receiving one or more network messages including APDU requests        that envelop a POS SAM applet (e.g., a Java Cap file from the        applet repository 504);    -   extracting the APDU requests from the received network messages;    -   sending the extracted APDU requests to the GP card manager 526        in a correct order for installation of the POS SAM (i.e.,        application applet 527) onto the secured element 529;    -   connecting to a personalization server (i.e., one of the service        provider servers 514) for a second security channel (may or may        not be the secured channel 518 depending on the server and/or        the path) between the personalization server and the newly        downloaded applet (i.e., POS SAM);    -   receiving one or more network messages for one or more separated        ‘STORE DATA APDU’; and    -   extracting and sending the ‘STORE DATA APDU’ to personalize POS        SAM; and    -   downloading and launching POS manager (i.e., application MIDlet        523).

Referring to FIG. 6A, there is shown an exemplary architecture 600, inwhich a portable device 630 is enabled as a mobile POS to conducte-commerce and m-commerce, according to one embodiment of the presentinvention. The portable device 630 comprises a baseband 624 and asecured element 629. A POS manager 623 is downloaded and installed inthe baseband 623 and a POS SAM 628 is installed and personalized in thesecured element 629 to enable the portable device 630 to act as a mobilePOS. Then a real time transaction 639 can be conducted between themobile POS enabled portable device 630 and an e-token enabled device 636(e.g., a single functional card or a portable device enabled with ane-purse). The e-token may represent e-money, e-coupon, e-ticket,e-voucher or any other forms of payment tokens in a device.

The real time transaction 639 can be conducted offline (i.e., withoutthe portable device connecting to a backend POS transaction server 613).However, the portable device 630 may connect to the backend POStransaction servers 613 over the cellular network 520 in certaininstances, for example, the amount of the transaction is over apre-defined threshold or limit, the e-token enabled device 636 needs atop-up or virtual top-up, transactional upload (single or in batch).

Records of accumulated offline transactions need to be uploaded to thebackend POS transaction server 613 for settlement. The upload operationsare conducted with the portable device 630 connecting to the POStransaction server 613 via a secured channel 618. Similar to theinstallation and personalization procedures, the upload operations canbe conducted in two different routes: the cellular communicationsnetwork 520; or the public network 521. The first route has beendescribed and illustrated in FIG. 6A.

The second route is illustrated in FIG. 6B showing an exemplaryarchitecture 640, in which a portable device 630 is enabled as a mobilePOS conducting a transaction upload in batch operation over a publicnetwork 521, according to an embodiment of the present invention.Records of offline transactions in the mobile POS are generally kept andaccumulated in a transaction log in the POS SAM 628. The transaction logare read by a contactless reader 634 into a POS agent 633 installed on acomputer 638. The POS agent 633 then connects to a POS transactionserver 613 over the public network 521 via a secured channel 619. Eachof the upload operations is marked as a different batch, which includesone or more transaction records. Data communication between the POS SAM628, the contactless reader 634 and the POS agent 632 in APDU containingthe transaction records. Network messages that envelop the APDU (e.g.,HTTP) are used between the POS agent 632 and the POS transaction server613.

In one embodiment, an exemplary batch upload process from the POSmanager 623 or the POS agent 633 includes:

-   -   sending a request to the POS SAM 628 to initiate a batch upload        operation;    -   retrieving accumulated transaction records in form of APDU        commands from a marked “batch” or “group” in the POS SAM 628        when the POS SAM 628 accepts the batch upload request;    -   forming one or more network messages containing the retrieved        APDU commands;    -   sending the one or more network messages to the POS transaction        server 613 via a secured channel 619;    -   receiving a acknowledgement signature from the POS transaction        server 613;    -   forwarding the acknowledgement signature in form APDU to the POS        SAM 628 for verification and then deletion of the confirmed        uploaded transaction records; and    -   repeating the step b) to step f) if there are additional        un-uploaded transaction records still in the same “batch” or        “group”.

Referring to FIG. 6C, there is shown a flowchart illustrating a process650 of conducting m-commerce using the portable device 630 enabled toact as a mobile POS with an e-token enabled device 636 as a singlefunctional card in accordance with one embodiment of the presentinvention. The process 650, which is preferably understood inconjunction with the previous figures especially FIG. 6A and FIG. 6B,may be implemented in software, hardware or a combination of both.

The process 650 (e.g., a process performed by the POS manager 623 ofFIG. 6A) starts when a holder of an e-token enabled device (e.g., aMifare card or an e-purse enabled cell phone emulating single functionalcard) desires to make a purchase or order a service with the mobile POS(i.e., the portable device 630). At 652, the portable device 630retrieving an e-token (e.g., tag ID of Mifare card) by reading thee-token enabled device. Next, the process 650 verifies whether theretrieved e-token is valid at 654. If the e-token enabled device 636 ofFIG. 6A is a single functional card (e.g., Mifare), the verificationprocedure performed by the POS manager 623 includes: i) reading the cardidentity (ID) of the card stored on an area that is unprotected orprotected by a well-known key; ii) sending an APDU request containingthe card ID to the POS SAM 628; iii) and receiving one or moretransformed keys (e.g., for transaction counter, an issuer data, etc.)generated by the POS SAM 628. If the one or more received transformedkeys are not valid, that is, the retrieved e-token being not valid, thenthe process 650 ends. Otherwise, the process 650 following the “yes”branch to 656, in which it is determined whether there is enough balancein the retrieved e-token to cover the cost of the current transaction.If the result is “no” at 656, the process 650 may optionally offer theholder to top-up (i.e., load, fund, finance) the e-token at 657. If“no”, the process 650 ends. Otherwise if the holder agrees to a realtime top-up of the e-token enabled device, the process 650 performseither a top-up or a virtual top-up operation at 658. Then the process650 goes back to 656. Whereas there is enough balance in the e-token,the process 650 deducts or debits the purchase amount from the e-tokenof the e-token enabled device 636 at 660. In the single functional cardcase, the one or more transformed keys are used to authorize thededuction. Finally at 662, records of one or more offline transactionsaccumulated in the POS SAM 628 are uploaded to the POS transactionserver 613 for settlement. The upload operations may be conducted foreach transaction or in batch over either the cellular communicationsnetwork 520 or the public domain network 521.

The top-up operations have been described and shown in the process 400of FIG. 4A. A virtual top-up operation is a special operation of thetop-up operation and typically is used to credit an e-token by a sponsoror donor. To enable a virtual top-up operation, the sponsor needs to setup an account that ties to an e-token enabled device (e.g., a singlefunctional card, a multi-functional card, an e-token enable cell phone,etc.). For example, an online account is offered by a commercial entity(e.g., business, bank, etc.). Once the sponsor has funded the e-token tothe online account, the holder of the e-token enabled device is able toreceive an e-token from the online account when connecting to the mobilePOS. Various security measures are implemented to ensure the virtualtop-up operation is secure and reliable. One exemplary usage of thevirtual top-up is that a parent (i.e., a sponsor) can fund an e-tokenvia an online account, which is linked to a cell phone (i.e., an e-tokenenabled device) of a child (i.e., the holder), such that the child mayreceive the funded e-token while the child makes a purchase at a mobilePOS. In addition to various e-commerce and m-commerce functionalitiesdescribed herein, the POS manager 623 is configured to provide variousquery operations, for example, a) checking the un-batched (i.e., notuploaded) balance accumulated in the POS SAM, b) listing the un-batchedtransaction log in the POS SAM, c) viewing details of a particulartransaction stored in the POS SAM, d) checking the current balance of ane-token enabled device, e) listing a transaction log of the e-tokenenabled device, and f) viewing details of a particular transaction ofthe e-token enabled device.

Referring to FIG. 6D, there is shown a flowchart illustrating anexemplary process 670 of conducting m-commerce using the portable device630 enabled to act as a mobile POS with an e-token enabled device 636 asa multi-functional card in accordance with one embodiment of the presentinvention. The process 670, which is preferably understood inconjunction with the previous figures especially FIG. 6A and FIG. 6B,may be implemented in software, hardware or a combination of both.

The process 670 (e.g., a process performed by the POS manager 623 ofFIG. 6A) starts when a holder of an e-token enabled device 636 (e.g., amulti-functional card or an e-purse enabled cell phone emulating amulti-functional card) desires to make a purchase or order a servicewith the mobile POS (i.e., the portable device 630). At 672, the process670 sends an initial purchase request to the e-token enabled device 636.The purchase amount is sent along with the initial request (e.g., APDUcommands). Next the process 670 moves to decision 674. When there is notenough balance in the e-token enabled device 636. The initial purchaserequest will be turned down as a return message received at the POSmanager 623. As a result, the process 670 ends with the purchase requestbeing denied. If there is enough balance in the e-token enabled device636, the result of the decision 674 is “yes” and the process 670 followsthe “yes” branch to 676. The received response (e.g., APDU commands)from the e-token enabled device 636 is forwarded to the POS SAM 628. Theresponse comprises information such as the version of the e-token keyand a random number to be used for establishing a secured channelbetween the applet (e.g., e-purse applet) resided on the e-token enableddevice 636 and the POS SAM 628 installed on the portable device 630.Then, at 678, the process 670 receives a debit request (e.g., APDUcommands) generated by the POS SAM 628 in response to the forwardedresponse (i.e., the response at 676). The debit request contains aMessage Authentication Code (MAC) for the applet (i.e., e-purse applet)to verify the upcoming debit operation, which is performed in responseto the debit request sent at 680. The process 670 moves to 682 in whicha confirmation message for the debit operation is received. In theconfirmation message, there are additional MACs, which are used forverification and settlement by the POS SAM 628 and the POS transactionserver 613, respectively. Next at 684, the debit confirmation message isforwarded to the POS SAM 628 for verification. Once the MAC is verifiedand the purchase transaction is recorded in the POS SAM 628, therecorded transaction is displayed at 686 before the process 670 ends. Itis noted that the e-commerce transaction described may be carried outoffline or online with the POS transaction server 613. Also when thereis not enough balance in the e-token enabled device, a top-up or fundingoperation may be performed using the process 400 illustrated in FIG. 4Aand FIG. 4B.

FIG. 7 shows an exemplary configuration in which a portable device isused for an e-ticketing application. A portable device 730 is configuredto include an e-purse 724. When an owner or holder of the portabledevice 730 desires to purchase a ticket for a particular event (e.g., aconcert ticket, a ballgame ticket, etc.), the owner can use e-purse 724to purchase a ticket through an e-ticket service provider 720. Thee-ticket service provider 720 may contact a traditional box officereservation system 716 or an online ticketing application 710 for ticketreservation and purchase. Then e-token (e.g., e-money) is deducted fromthe e-purse 724 of the portable device 730 to pay the ticket purchase toa credit/debit system 714 (e.g., a financial institute, a bank). A SAM718 is connected to the e-ticket service provider 720 so that theauthentication of e-purse 724 in the portable device 730 can be assured.Upon a confirmation of the payment is received, the e-ticket isdelivered to the portable device 730 over the air (e.g., a cellularcommunications network) and stored onto a secured element 726electronically, for example, an e-ticket code or key or password. Lateron, when the owner of the portable device 730, the ticket holder,attends the particular event, the owner needs only to let a gatecheck-in reader 734 to read the stored e-ticket code or key in theportable device 730. In one embodiment, the gate check-in reader 734 isa contactless reader (e.g., an ISO 14443 complied proximity couplingdevice). The portable device 730 is a NFC capable mobile phone.

The invention is preferably implemented by software, but can also beimplemented in hardware or a combination of hardware and software. Theinvention can also be embodied as computer readable code on a computerreadable medium. The computer readable medium is any data storage devicethat can store data which can thereafter be read by a computer system.Examples of the computer readable medium include read-only memory,random-access memory, CD-ROMs, DVDs, magnetic tape, optical data storagedevices, and carrier waves. The computer readable medium can also bedistributed over network-coupled computer systems so that the computerreadable code is stored and executed in a distributed fashion.

The present invention has been described in sufficient details with acertain degree of particularity. It is understood to those skilled inthe art that the present disclosure of embodiments has been made by wayof examples only and that numerous changes in the arrangement andcombination of parts may be resorted without departing from the spiritand scope of the invention as claimed. Accordingly, the scope of thepresent invention is defined by the appended claims rather than theforegoing description of embodiment.

What we claim is:
 1. A method for personalizing a secure element, themethod comprising: initiating by a mobile device to communicate with aserver to determine whether the secure element is registered with adesignated party, wherein the secure element is a component coupled tothe mobile device remotely located with respect to the server; receivinga request from the server after the server verifies that the secureelement has been registered with the designated party, wherein therequest is a command causing a module in the mobile device to retrievedevice information of the secure element; sending the device informationof the secure element from the mobile device to the server in respondingto the request, wherein the device information, preloaded in the secureelement by a manufacturer thereof, includes an identifier of the secureelement, manufacturer information and a batch number of the secureelement; updating certain data in the secure element when some of thedevice information has been updated and received via the server, whereinthe some of the device information is maintained in a database coupledto the server; receiving at least a first key set securely andwirelessly from the server, wherein the first key set is generated inthe server from a master key in accordance with the device informationof the secure element; storing the first key set in the secure element;and storing a second key set in the secure element, where the second keyset is generated in the server and delivered to the secure elementthrough a channel secured with the first key set.
 2. The method asrecited in claim 1, further comprising: provisioning an application withthe secure element by receiving a third key set in the secure elementthrough a channel secured with the second key set, wherein the third keyset allows the application executed in the mobile device to complete asecure transaction with another device.
 3. The method as recited inclaim 2, wherein the mobile device is a Near Field Communication(NFC)-enabled device accommodating the secure element that must bepersonalized before the NFC-enabled device is used to provide varioustransactions with a party over a data network.
 4. The method as recitedin claim 3, wherein the party is a financial agent, and one of thevarious transactions is related to a financial transaction with thefinancial agent.
 5. The method as recited in claim 1, wherein, based onthe device information of the secure element, the server is caused toretrieve corresponding default Issuer Security Domain (ISD) informationof the secure element from a provider thereof to generate the first keyset.
 6. The method as recited in claim 5, wherein the secure elementincludes the default issuer security domain (ISD) for receiving thefirst key set from the server, the default ISD is then updated after thefirst key set from the server is received in the secure element.
 7. Themethod as recited in claim 6, wherein the first key set is generatedonly once while the second key set is generated pertaining to a serviceprovider, an additional second key set is generated when there isanother service provider, the third key set includes operation keysspecifically for the application.
 8. The method as recited in claim 7,wherein an additional third key set is generated and stored in thesecure element for each additional application installed in the mobiledevice.
 9. The method as recited in claim 1, further comprising: sendingto a designated server an identifier identifying the applicationtogether with the device information of the secure element; establishinga secured channel between the secure element and the designated serverusing a derived Issuer Security Domain (ISD) key set installed on thesecure element; and installing a supplemental security domains (SSD) keywhen there is no such a SSD associated with the application.
 10. Themethod as recited in claim 9, further comprising: receiving parametersthrough the supplemental SSD to activate the application; and notifyinga provider of the application about a status of the application with thesecure element.
 11. A method for personalizing a secure elementassociated with a mobile device, the method comprising: receiving ademand in a server from a mobile device for communication therewith;sending a request from the server to the mobile device to request deviceinformation of the secure element after the server determines that themobile device is registered therewith, wherein the device information isa sequence of characters uniquely identifying the secure element, andthe request is a command causing the mobile device to retrieve themobile device information from the secure element; generating at least afirst key set in accordance with the device information; delivering thefirst key set through a secured channel over a data network to themobile device, wherein the first key set is caused to be stored in thesecure element with the mobile device, wherein the secured channel isestablished by a default key originally in the secure element; anddefault key is replaced by the first key set; and storing a second keyset in the secure element, where the second key set is generated in theserver and delivered to the secure element through a channel securedwith the first key set; and provisioning an application with the secureelement by receiving a third key set in the secure element through achannel secured with the second key set, wherein the third key setallows the application executed in the mobile device to complete asecure transaction with another device.
 12. The method as recited inclaim 11, further comprising: notifying related parties that the secureelement is now personalized for subsequent trusted transactions.
 13. Themethod as recited in claim 11, wherein the server is part of a TrustedService Management (TSM) which is a collection of services configured todistribute and manage contactless services for customers signed up withthe TSM, and provide data exchanges among different parties to makecommerce possible with the mobile device.
 14. The method as recited inclaim 11, wherein the device information includes an identifier of thesecure element, manufacturer information and a batch number.
 15. Themethod as recited in claim 12, further comprising: retrievingcorresponding default Issuer Security Domain (ISD) information of thesecure element from a provider thereof based on the device informationof the secure element.
 16. The method as recited in claim 11, whereinthe secure element is in form of a smart card or an integrated circuit(IC), and includes at least one issuer security domain (ISD).
 17. Themethod as recited in claim 11, wherein the secure element is a softwaremodule upgradable by overwriting some or all of components therein, thesoftware module is obtained and updated by downloading updatingcomponents from a designated server.
 18. The method as recited in claim11, wherein the mobile device is a Near Field Communication(NFC)-enabled device accommodating the secure element that must bepersonalized before the NFC-enabled device is used to provide varioustransactions with a party over a data network.
 19. The method as recitedin claim 18, wherein the party is a financial agent, and one of thevarious transactions is related to a financial transaction with thefinancial agent.
 20. The method as recited in claim 11, furthercomprising: facilitating a designated server to receive an identifieridentifying an application together with the device information of thesecure element and establish a secured channel between the secureelement and the designated server using a derived Issuer Security Domain(ISD) key set installed on the secure element; and determining whetherthere is a supplemental security domain (SSD) key set associated withthe application, and installing the SSD key when there is no such a SSDassociated with the application.